Webpack 5 it is, since it speeds up builds quite a lot.

A warm (with cache) Webpack development build with small changes now takes a mere 7 seconds, and a production build is down to 24s 🚀

There are still a few things to do or wait for:

• Update to Webpack 5
  • Wait for Webpack 5 RC (webpack 5 release plan webpack/webpack#11406)
• Update to webpack-cli 4.0
  • Currently blocked by webpack serve fails with TypeError: cli.commandLineArgs is not a function webpack/webpack-cli#1814
  • Somehow that update seems to have disabled caching? For yarn webpack serve cache files are written to disk, but not for yarn webpack? (Project with webpack-cli@4.0.0-rc.0 doesn't use cache webpack/webpack-cli#1842)
• Enable Webpack 5 persistent caching
• Wait for dotenv-webpack Webpack 5 support (feat: supporting webpack 5 mrsteele/dotenv-webpack#234)
  • Revert changes to settings.ts after upgrading dotenv-webpack
• Switch away from filenamify, since it requires path
  • Alternatively, wait for Add the possibility to use filenamify with webpack 5, without adding a path polyfill sindresorhus/filenamify#16
  • Alternative, use a fork of the project
• Switch away from csv-parse, since it requires Buffer
• Update Storybook config to also work with Webpack 5
  • Wait for webpackVersion check doesn't work if multiple versions of webpack are in use webpack-contrib/mini-css-extract-plugin#600 to be fixed
• Consolidate commits
• Go through deprecation warnings (most likely caused by Webpack loaders/plugins that are not yet compatible)
  • Maybe find a replacement for the deprecated webpack-manifest-plugin
• Go through cache warnings
• Consolidate commits
• Look out for regressions on staging

The changes csv-parse -> papaparse and filenamify -> sanitize-filename are needed because Webpack 5 removes automatic Node polyfills.
We could still manually polyfill those, but I thought it to be cleaner to use browser-first modules instead.